AWS Systems Manager Patch Manager でパッチ適用前後にアクションが実行できるようになりました！

#AWS Systems Manager（SSM）

#AWS

園部治

2021.02.05

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Systems Manager Patch Manager（以下、 Patch Manager）で、アップデートがありました！

Take actions before and after patching to improve safety during patch installation

パッチ適用する際に、適用以外にも付随する作業があるケースが多いのではないかと思います。例えば、設定ファイルバックアップやクラスターのような構成からの一時的な除外、また実行後の結果確認や影響確認などなど。このようなちょっとした前処理や後処理を Patch Manager の中で任意のアクション（ Run Command ）として指定し、実行出来るようになりました！

引用：「今すぐパッチ適用」画面より

インストール前、インストール後、再起動後の三つのライフサイクルをトリガーに実行することが可能です。

現時点では、ユーザーが作成した Run Command ドキュメントのみ指定可能です。

内部的には AWS-RunPatchBaselineWithHooks ドキュメントが新たにリリースされ、こちらを用いて実現しています。詳細な前提条件やパラメータは、リンクからドキュメントガイドをご確認ください。特に SSM Agent 3.0.502 以降が前提条件となっていることは要注意です。

また、具体的なサンプルやユースケースも紹介されています。

Walkthrough: Update application dependencies, patch an instance, and perform an application-specific health check

やってみた

前置き

下記 EC2 を用意しました。

Amazon Linux2 （ amzn2-ami-hvm-2.0.20191024.3-x86_64-gp2 ） x 2台
起動時にアップデートが実行されないように設定
最新バージョンの SSM Agentがインストール

Run Command ドキュメント作成

今回は RunShellScript で echo を実行するドキュメントを作成します。


{
  "schemaVersion": "2.2",
  "description": "Pre Action for Pacth Install",
  "mainSteps": [
    {
      "action": "aws:runShellScript",
      "name": "blogsample",
      "inputs": {
        "runCommand": [
          "echo Start Pre Actions Execute."
        ]
      }
    }
  ]
}

それぞれ内容に変更したドキュメントを作成します。

PreAction_for_PacthInstall
PostAction_for_PacthInstall
OnExitAction_for_PacthInstall

実際に動作を検証するために Patch Manager で適用を実施してみます。実は検証する中で Patch Manager の実行方法で OnExit（再起動）時の動作が異なったため、分けて記載します。（2021/2/5 時点）

パッチ適用「今すぐパッチ適用」編

AWS System Manager >>> パッチマネージャー >>> 今すぐパッチ適用

インストールまで実行
必要に応じて再起動実行を許可
先に作成した Run Command ドキュメントをそれぞれのライフサイクルに指定

今すぐパッチ適用 を実行

しばらくすると処理が終了するため、結果を確認します。

AWS System Manager >>> Run Command >>> コマンド履歴 >>> 該当コマンド

ここで、指定したはずの On Exit 向けの Run Command ドキュメントが適用されていないことに気付きます。 AWS-Noop はデフォルトで、何もしないことを意味します。

詳細なログを確認していきます。

Pre-patch hook setup completed successfully. Proceeding with installation next. と出力されセットが完了したことが確認できます。

インストール前に実行指定したドキュメントが実行されています（echo が出力されている）

インストール後に実行指定したドキュメントが実行されています（echo が出力されている）

再起動後に指定したはずのドキュメントは存在せず、実行されていません。先に指定したものが反映されていないことから正しい結果ではあります。。

実際に、再起動をともなうようなアップデートがなかったのかとも考えましたが、アップデート内容やログから再起動自体はしていることがわかります。


# cat /var/log/yum.log
Feb 05 01:53:11 Updated: 1:openssl-libs-1.0.2k-19.amzn2.0.4.x86_64
Feb 05 01:53:11 Updated: libxml2-2.9.1-6.amzn2.4.1.x86_64
Feb 05 01:53:11 Updated: 32:bind-license-9.11.4-9.P2.amzn2.0.3.noarch
Feb 05 01:53:11 Updated: 32:bind-libs-lite-9.11.4-9.P2.amzn2.0.3.x86_64
Feb 05 01:53:11 Updated: 12:dhcp-libs-4.2.5-77.amzn2.1.1.x86_64
Feb 05 01:53:11 Updated: 12:dhcp-common-4.2.5-77.amzn2.1.1.x86_64
Feb 05 01:53:11 Updated: 32:bind-libs-9.11.4-9.P2.amzn2.0.3.x86_64
Feb 05 01:53:12 Installed: 32:bind-export-libs-9.11.4-26.P2.amzn2.2.x86_64
Feb 05 01:53:12 Updated: nss-3.44.0-7.amzn2.x86_64
Feb 05 01:53:12 Updated: nss-sysinit-3.44.0-7.amzn2.x86_64
Feb 05 01:53:12 Installed: 2:libpng-1.5.13-8.amzn2.x86_64
Feb 05 01:53:12 Updated: freetype-2.8-14.amzn2.1.x86_64
Feb 05 01:53:12 Updated: 2:microcode_ctl-2.1-47.amzn2.0.7.x86_64
Feb 05 01:53:15 Installed: kernel-4.14.214-160.339.amzn2.x86_64
Feb 05 01:53:15 Updated: python-pillow-2.0.0-20.gitd1c6db8.amzn2.0.1.x86_64
Feb 05 01:53:15 Updated: nss-tools-3.44.0-7.amzn2.x86_64
Feb 05 01:53:15 Updated: 12:dhclient-4.2.5-77.amzn2.1.1.x86_64
Feb 05 01:53:16 Updated: 32:bind-utils-9.11.4-9.P2.amzn2.0.3.x86_64
Feb 05 01:53:16 Updated: libxml2-python-2.9.1-6.amzn2.4.1.x86_64
Feb 05 01:53:16 Updated: 1:openssl-1.0.2k-19.amzn2.0.4.x86_64
Feb 05 01:53:16 Updated: sqlite-3.7.17-8.amzn2.1.1.x86_64
Feb 05 01:53:16 Updated: libnghttp2-1.41.0-1.amzn2.x86_64
Feb 05 01:53:16 Updated: sudo-1.8.23-4.amzn2.2.1.x86_64
Feb 05 01:53:16 Updated: kernel-tools-4.14.214-160.339.amzn2.x86_64
Feb 05 01:53:17 Updated: libicu-50.2-4.amzn2.x86_64

# cat /var/log/messages

Feb  5 01:56:03 ip-192-168-1-152 systemd: Starting Switch Root...
Feb  5 01:56:03 ip-192-168-1-152 systemd: Switching root.
Feb  5 01:56:03 ip-192-168-1-152 journal: Journal stopped
Feb  5 01:56:04 ip-192-168-1-152 journal: Runtime journal is using 6.1M (max allowed 49.1M, trying to leave 73.7M free of 479.3M available → current limit 49.1M).
Feb  5 01:56:04 ip-192-168-1-152 systemd-journald[939]: Received SIGTERM from PID 1 (systemd).
Feb  5 01:56:04 ip-192-168-1-152 kernel: systemd: 25 output lines suppressed due to ratelimiting
Feb  5 01:56:04 ip-192-168-1-152 kernel: SELinux:  Disabled at runtime.
Feb  5 01:56:04 ip-192-168-1-152 kernel: audit: type=1404 audit(1612490164.064:2): selinux=0 auid=4294967295 ses=4294967295
Feb  5 01:56:04 ip-192-168-1-152 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
Feb  5 01:56:04 ip-192-168-1-152 systemd[1]: Inserted module 'ip_tables'
Feb  5 01:56:04 ip-192-168-1-152 journal: Journal started
Feb  5 01:56:04 ip-192-168-1-152 systemd: systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN)

OnExit 時の動作は不明瞭ですがインストール前後に指定した Run Command ドキュメントが実行されることは確認が出来ました！実行内容が echo なので微妙ではありますが、対象リソースやサービスに応じて色々実施できそうな雰囲気がわかりました。

パッチ適用「Run Command」編

OnExit の部分が気になったため、「今すぐパッチ適用」ではなく Run Command から AWS-RunPatchBaselineWithHooks を実行してみます。

AWS Systems Manager >>> Run Command >>> コマンドの実行

こちらも「今すぐパッチ適用」と同様の設定を実施します。

インストールまで実行
必要に応じて再起動実行を許可
先に作成した Run Command ドキュメントをそれぞれのライフサイクルに指定

実行 を選択します。

こちらもしばらくすると完了するので、確認していきます。

AWS System Manager >>> Run Command >>> コマンド履歴 >>> 該当コマンド

こちらでは OnExitHookDocName に指定した Run Command ドキュメントが設定されていることが確認できます。

詳細なログを確認していきます。

こちらでは OnExit に実行指定したドキュメントが実行されています!（echo が出力されている）

さいごに

現時点（2021/2/5 時点）での実行方法による動作の違いには注意が必要ですが、機能としては良いものではないでしょうか！パッチ適用はサービス影響の少ない夜間や早朝に実施したいから Patch Manager などのサービスを活用したいけど、細かな付随する作業を実現するには、少し手がかかるからと断念されていた方も、今一度検討しても良いかもしれません！